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Locator/ID Separation Protocol (LISP) Impact 

Abstract 
The Locator/ID Separation Protocol (LISP) aims to improve the 
Internet routing scalability properties by leveraging three 
principles: address role separation, encapsulation, and mapping. In 
this document, based on implementation work, deployment experiences, 
and theoretical studies, we discuss the impact that the deployment of 
LISP can have on both the routing infrastructure and the end user. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7834. 
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Les 


Introduction 


The Locator/ID Separation Protocol (LISP) relies on three principles 
to improve the scalability properties of Internet routing: address 
role separation, encapsulation, and mapping. When invented, LISP was 
targeted at solving the Internet routing scaling problem [RFC4984]. 
There have now been years of implementations and experiments 
examining the impact and open questions of using LISP to improve 
inter-domain routing scalability. Experience has shown that because 
LISP utilizes mapping and encapsulation technologies, it can be 
deployed and used for purposes that go beyond routing scalability. 
For example, LISP provides a mean for a LISP site to precisely 
control its inter-domain outgoing and incoming traffic, with the 
possibility to apply different policies to different domains 


exchanging traffic with it. LISP can also be used to ease the 
transition from IPv4 to IPv6 as it allows the transport of IPv4 over 
IPv6 or IPv6 over IPv4. Furthermore, LISP also supports inter-domain 
multicast. 


Leveraging implementation and deployment experience, as well as 
research work, this document describes, at a high level, the impacts 
and open questions still seen in LISP. This information is 
particularly useful for considering future approaches and to support 
further experimentation to clarify some large open questions (e.g., 
around the operations). LISP utilizes a tunnel-based data plane and 
a distributed control plane. LISP requires some new functionalities, 
such as reachability mechanisms. Because LISP is more than a simple 
encapsulation technology and is a new technology, until even more 
deployment experience is gained, some open questions related to LISP 
deployment and operations remain. As an encapsulation technology, 
there may be concerns on reduced Maximum Transmission Unit (MTU) size 
in some deployments. An important impact of LISP is on network 
operations related to resiliency and troubleshooting. As LISP relies 
on cached mappings and on encapsulation, resiliency during failures 
and troubleshooting may be more difficult. Also, the use of 
encapsulation may make failure detection and recovery slower, and it 
will require more coordination than with a single, non-encapsulated, 
routing domain solution. 
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LISP in a Nutshell 


LISP relies on three principles: address role separation, 
encapsulation, and mapping. 


The address space is divided into two sets that have different 
semantic meanings: the Routing Locators (RLOCs) and the Endpoint 
Identifiers (EIDs).  RLOCs are addresses typically assigned from the 
Provider Aggregatable (PA) address space. The EIDs are attributed to 
the nodes in the edge networks, by a block of contiguous addresses, 
which are typically Provider Independent (PI). To limit the 
scalability problem, LISP only requires the PA routes towards the 
RLOCs to be announced in the provider infrastructure. Whereas for 
non-LISP deployments, the EIDs need to be propagated as well. 


LISP routers are used at the boundary between the EID and the RLOC 
Spaces. Routers used to exit the EID space (towards the provider 
domain) are called Ingress Tunnel Routers (ITRs), and those used to 
enter the EID space (from the provider domain) are called the Egress 
Tunnel Routers (ETRs). When a host sends a packet to a remote 
destination, it sends it as in the non-LISP Internet. The packet 
arrives at the border of its site at an ITR. Because EIDs are not 
routable on the Internet, the packet is encapsulated with the source 
address set to the ITR RLOC and the destination address set to the 
ETR RLOC. The encapsulated packet is then forwarded in the provider 
domain until it reaches the selected ETR. The ETR de-encapsulates 
the packet and forwards it to its final destination. The acronym xTR 
Stands for Ingress/Egress Tunnel Router and is used for a router 
playing these two roles. 


The correspondence between EIDs and RLOCs is given by the mappings. 
When an ITR needs to find ETR RLOCs that serve an EID, it queries a 
mapping system. With the LISP Canonical Address Format (LCAF) 
[LISP-LCAF], LISP is not restricted to the Internet protocol for the 
EID addresses. With LCAF, any address type can be used as EID (the 
address is only the key for the mapping lookup).  LISP can transport, 
for example, Ethernet frames over the Internet. 


An introduction to LISP can be found in [RFC7215]. The LISP 
Specifications are given in [RFC6830], [RFC6833], [LISP-DDT], 
[RFC6836], [RFC6832], and [RFC6834]. 
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LISP for Scaling the Internet Routing Architecture 


The original goal of LISP was to improve the scalability properties 
of the Internet routing architecture.  LISP utilizes traffic 
engineering and stub Autonomous System (AS) prefixes (not announced 
anymore in the Default-Free Zone (DFZ)), so that routing tables are 
smaller and more stable (i.e., they experience less churn). 
Furthermore, at the edge of the network, information necessary to 
forward packets (i.e., the mappings) is obtained on demand using a 
pull model (whereas the current Internet BGP model uses a push 
model). Therefore, the scalability of edge networks is less 
dependent on the Internet's size and more related to its traffic 
matrix. This scaling improvement has been proven by several studies 
(see below). The research studies cited hereafter are based on the 
following assumptions: 


o EID-to-RLOC mappings follow the same prefix size as the current 
BGP routing infrastructure (current PI addresses only); 


o EIDs are used only at the stub ASes, not in the transit ASes; and 


o the RLOCs of an EID prefix are deployed at the edge between the 
stubs owning the EID prefix and the providers, allocating the 
RLOCs in a PA mode. 


The above assumptions are inline with [RFC7215] and current LISP 
deployments. It is recognized these assumptions may change in the 
longer term. [KIF13] and [CDLC] explore different EID prefix space 
Sizes and still show results that are consistent and equivalent to 
the above assumptions. 


Quoitin et al. [QIdLBO7] show that the separation between locator and 
identifier roles at the network level improves the routing 
scalability by reducing the Routing Information Base (RIB) size (up 
to one order of magnitude) and increases path diversity and thus the 
traffic engineering capabilities.  [IB0O7] and [KIF13] show, based on 
real Internet traffic traces, that the number of mapping entries that 
must be handled by an ITR of a network with up to 20,000 users is 
limited to few tens of thousands; the signaling traffic (i.e., 
Map-Request/Map-Reply packets) is in the same order of magnitude 
similar to DNS request/reply traffic; and the encapsulation overhead, 
while not negligible, is very limited (in the order of few percentage 
points of the total traffic volume). 


Previous studies consider the case of a timer-based cache eviction 
policy (i.e., mappings are deleted from the cache upon timeout), 
while [CDLC] has a more general approach based on the Least Recently 
Used (LRU) eviction policy, proposing an analytic model for the EID- 
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to-RLOC cache size when prefix-level traffic has a stationary 
generating process. The model shows that miss rate can be accurately 
predicted from the EID-to-RLOC cache size and a small set of easily 
measurable traffic parameters. The model was validated using four 
one-day-long packet traces collected at egress points of a campus 
network and an academic exchange point considering EID prefixes as 
being of the same size as BGP prefixes. Consequently, operators can 
provision the EID-to-RLOC cache of their ITRs according to the miss 
rate they want to achieve for their given traffic. 


Results in [CDLC] indicate that for a given target miss ratio, the 
Size of the cache depends only on the parameters of the popularity 
distribution; the size of the cache is independent of the number of 
users (the size of the LISP site) and the number of destinations (the 
Size of the EID prefix space). Assuming that the popularity 
distribution remains constant, this means that as the number of users 
and the number of destinations grow, the cache size needed to obtain 
a given miss rate remains constant O(1). 


LISP usually populates its EID-to-RLOC cache in a pull mode, which 
means that mappings are retrieved on demand by the ITR. The main 
advantage of this mode is that the EID-to-RLOC cache size only 
depends on the traffic characteristics at the ITR and is independent 
of the size of the provider domain. This benefit comes at the cost 
of some delay to transmit the packets that do not hit an entry in the 
cache (for which a mapping has to be learned). This delay is bound 
by the time necessary to retrieve the mapping from the mapping 
System. Moreover, similarly to a push model (e.g., BGP), the pull 
model induces signaling messages that correspond to the retrieval of 
mappings upon cache miss. The difference being that the signaling 
load only depends on the traffic at the ITR and is not triggered by 
external events such as in BGP. [CDLC] shows that the miss rate is a 
function of the EID-to-RLOC cache size and traffic generation 
process, and [CDLC], [SDIB08], and [SDIB08] show from traffic traces 
that, in practice, the cache miss rate, and thus the signaling rate, 
remain low. 


4. Beyond Scaling the Internet Routing Architecture 


LISP is more than just a scalability solution; it is also a tool to 
provide both incoming and outgoing traffic engineering [S11] 
[LISP-TE], it can be used as an IPv6 transition at the routing level, 
and it can be used for inter-domain multicast [RFC6831] [LISP-RE]. 
Also, LISP has been identified for use to support devices' Internet 
mobility [LISP-MN] and to support virtual machines' mobility in data 
centers and multi-tenant VPNs. These last two uses are not discussed 
further as they are out of the scope of the current LISP Working 
Group charter. 
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A key advantage of the LISP architecture is that it facilitates 
routing in environments where there is little to no correlation 
between network endpoints and topological location. In service- 
provider environments, this application is needed in a range of 
consumer use cases that require an inline anchor to deliver a service 
to subscribers. Inline anchors provide one of three types of 
capabilities: 


o enable mobility of subscriber endpoints 
o enable chaining of middlebox functions and services 
o enable functions to be scaled out seamlessly 


Without LISP, the approach commonly used by operators is to aggregate 
service anchors in custom-built boxes. This limits deployments as 
endpoints can only move on the same mobile gateway, functions can be 
chained only if traffic traverses the same wire or the same Deep 
Packet Inspection (DPI) box, and capacity can be scaled out only if 
traffic fans out to/from a specific load balancer. 


With LISP, service providers are able to distribute, virtualize, and 
instantiate subscriber-service anchors anywhere in the network. 
Typical use cases for virtualized inline anchors and network 
functions include Distributed Mobility and Virtualized Evolved Packet 
Core (vEPC), Virtualized Customer Premise Equipment (vCPE), where 
functionality previously anchored at a customer premise is now 
dynamically allocated in the network, Virtualized SGi LAN, Virtual IP 
Multimedia Subsystems (IMSs), Virtual Session Border Controller 
(SBC), etc. 


ConteXtream [ConteXtream] has been deploying map-assisted overlay 
networks since 2006, first with a proprietary solution, then evolving 
to standard LISP. The solution has been deployed in production in 
three tier-1 operators spanning hundreds of millions of subscribers. 
Map-assisted overlays had been primarily used to map subscriber flows 
to services resources dynamically based on profiles and conditions. 
Specifically, it has been used to map mobile subscribers to value- 
added/optimization services, broadband subscribers to telephony 
Services, and fixed-mobile subscribers to Broadband Network Gateway 
(BNG) functions and Internet access services. The LISP map-assisted 
overlay architecture is used to optimally resolve subscriber to 
services, functions, instances, and IP overlay aggregation locations 
on a per-flow basis and just in time. 
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4.1. Traffic Engineering 


In the current (non-LISP) routing infrastructure, addresses used by 
stub networks are globally routable, and the routing system 
distributes the routes to reach these stubs. With LISP, the EID 
prefixes of a LISP site are not routable in the DFZ; mappings are 
needed in order to determine the list of LISP routers to contact to 
forward packets. This difference is significant for two reasons. 
First, packets are not forwarded to a site but to a specific router. 
Second, a site can control the entry points for its traffic by 
controlling its mappings. 


For traffic engineering purposes, a mapping associates an EID prefix 
to a list of RLOCs. Each RLOC is annotated with a priority anda 
weight. When there are several RLOCs, the ITR selects the one with 
the highest priority and sends the encapsulated packet to this RLOC. 
If several RLOCs with the highest priority exist, then the traffic is 
balanced proportionally to their weight among such RLOCs. Traffic 
engineering in LISP thus allows the mapping owner to have a fine- 
grained control on the primary and backup path for its incoming and 
outgoing packet use. In addition, it can share the load among its 
links. An example of the use of such a feature is described by 
Saucez et al. [SDIB08], which shows how to use LISP to direct 
different types of traffic on different links having different 
capacity. 


Traffic engineering in LISP goes one step further, as every Map- 
Request contains the source EID address of the packet that caused a 
cache miss and triggered the Map-Request. It is thus possible for a 
mapping owner to differentiate the answer (Map-Reply) it gives to 
Map-Requests based on the requester. This functionality is not 
available today with BGP because a domain cannot control exactly the 
routes that will be received by domains that are not in the direct 
neighborhood. 


4.2. LISP for IPv6 Co-existence 


The LISP encapsulation mechanism is designed to support any 
combination of address families for locators and identifiers. It is 
then possible to bind IPv6 EIDs with IPv4 RLOCs and vice versa. This 
allows transporting IPv6 packets over an IPv4 network (or IPv4 
packets over an IPv6 network), making LISP a valuable mechanism to 
ease the transition to IPv6. 


An example is the case of the network infrastructure of a data center 
being IPv4 only while dual-stack front-end load balancers are used. 
In this scenario, LISP can be used to provide IPv6 access to servers 
even though the network and the servers only support IPv4. Assuming 
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that the data center’s ISP offers IPv6 connectivity, the data center 
only needs to deploy one (or more) xTR(s) at its border with the ISP 
and one (or more) xTR(s) directly connected to the load balancers. 
The xTR(s) at the ISP's border tunnels IPv6 packets over IPv4 to the 
xTR(s) directly attached to the load balancer. The load balancer's 
XTR de-encapsulates the packets and forwards them to the load 
balancer, which act as a proxy, translating each IPv6 packet into an 
IPv4 packet.  IPv4 packets are then sent to the appropriate servers. 
Similarly, when the server's response arrives at the load balancer, 
the packet is translated back into an IPv6 packet and forwarded to 
its xTR(s), which in turn will tunnel it back, over the IPv4-only 
infrastructure, to an xTR connected to the ISP. The packet is then 
de-encapsulated and forwarded to the ISP natively in IPv6. 


4.3.  Inter-domain Multicast 


LISP has native support for multicast [RFC6831]. From the data-plane 
perspective, at a multicast-enabled xTR, an EID-sourced multicast 
packet is encapsulated in another multicast packet and subsequently 
forwarded in an RLOC-level distribution tree. Therefore, xTRs must 
participate in both EID and RLOC-level distribution trees.  Control- 
plane wise, since group addresses have no topological significance, 
they need not be mapped. It is worth noting that, to properly 
function, LISP-Multicast requires that inter-domain multicast be 
available. 


LISP Replication Engineering (LISP-RE) [LISP-RE] [CDM12] leverages 
LISP messages [LISP-MULTI-SIGNALING] for multicast state distribution 
to construct xTR-based inter-domain multicast distribution trees when 
inter-domain multicast support is not available. Simulations of 
three different management strategies for low-latency content 
delivery show that such overlays can support thousands of member 
XTRs, support hundreds of thousands of end hosts, and deliver content 
at latencies close to unicast ones [CDM12]. It was also observed 
that high client churn has a limited impact on performance and 
management overhead. 


Similar to LISP-RE, "Signal-Free LISP Multicast" [LISP-SFM] can be 
used when the core network does not provide multicast support. But 
instead of using signaling to build inter-domain multicast trees, 
signal-free exclusively leverages the map server for multicast state 
storage and distribution. As a result, the source ITR generally 
performs head-end replication, but it might also be used to emulate 
LISP-RE distribution trees. 
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5. Impact of LISP on Operations and Business Models 


Numerous implementation efforts ([IOSNXOS], [OpenLISP], [LISPmob], 
[LISPClick], [LISPcp], and [LISPfritz]) have been made to assess the 
specifications, and additionally, interoperability tests [Was09] have 
been successful. A worldwide large deployment in the international 
lisp4.net testbed, which is currently composed of nodes running at 
least three different implementations, will allow us to learn further 
operational aspects related to LISP. 


The following sections distinguish the impact of LISP on LISP sites 
from the impact on non-LISP sites. 


5.1. Impact on Non-LISP Traffic and Sites 


LISP has no impact on traffic that has neither LISP origin nor LISP 
destination. However, LISP can have a significant impact on traffic 
between a LISP site and a non-LISP site. Traffic between a non-LISP 
Site and a LISP site is subject to the same issues as those observed 
for LISP-to-LISP traffic but also has issues specific to the 
transition mechanism that allow the LISP site to exchange packets 
with a non-LISP site [RFC6832] [RFC7215]. 


The transition requires setup of proxy tunnel routers (PxTRs). 
Proxies cause what is referred to as path stretch (i.e., a 
lengthening of the path compared to the topological shortest path) 
and make troubleshooting harder. There are still questions related 
to PxTRs that need to be answered: 


o Where to deploy PxTRs? The placement in the topology has an 
important impact on the path stretch. 


o How many PxTRs? The number of PxTRs has a direct impact on the 
load and the impact of the failure of a PXTR on the traffic. 


o What part of the EID space? Will all the PxTRs be proxies for the 
whole EID space, or will it be segmented between different PxTRs? 


o Who operates PxTRs? An important question to answer is related to 
the entities that will deploy PxTRs: how will they manage their 
additional Capital Expenditure (CAPEX) / Operating Expenses (OPEX) 
associated with PxTRs? How will the traffic be carried with 
respect to security and privacy? 


A PXTR will also normally advertise in BGP the EID prefix for which 
they are proxies. However, if proxies are managed by different 
entities, they will belong to different ASes. In this case, we need 
to be sure that this will not cause Multi-Origin AS (MOAS) issues 
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that could negatively influence routing. Moreover, it is important 
to ensure that the way EID prefixes will be de-aggregated by the 
proxies will remain reasonable so as not to contribute to BGP 
scalability issues. 


5.2. Impact on LISP Traffic and Sites 


LISP is a protocol based on the map-and-encap paradigm, which has the 
positive impacts that we have summarized in the above sections. 
However, LISP also has impacts on operations: 


MTU issue: As LISP uses encapsulation, the MTU is reduced; this has 
implications on potentially all of the traffic. However, in 
practice, on the lisp4.net network, no major issue due to the MTU 
has been observed. This is probably due to the fact that current 
end-host stacks are well designed to deal with the problem of MTU. 


Resiliency issue: The advantage of flexibility and control offered 
by the Locator/ID separation comes at the cost of increasing the 
complexity of the reachability detection. Indeed, identifiers are 
not directly routable and have to be mapped to locators, but a 
locator may be unreachable while others are still reachable. This 
is an important problem for any tunnel-based solution. In the 
current Internet, packets are forwarded independently of the 
border router of the network meaning that, in case of the failure 
of a border router, another one can be used. With LISP, the 
destination RLOC specifically designates one particular ETR; 
hence, if this ETR fails, the traffic is dropped, even though 
other ETRs are available for the destination site. Another 
resiliency issue is linked to the fact that mappings are learned 
on demand. When an ITR fails, all its traffic is redirected to 
other ITRs that might not have the mappings requested by the 
redirected traffic. Existing studies [SKI12] [SD12] show, based 
on measurements and traffic traces, that failure of ITRs and RLOC 
are infrequent but that when such failure happens, a critical 
number of packets can be dropped. Unfortunately, the current 
techniques for LISP resiliency, based on monitoring or probing, 
are not rapid enough (failure recovery on the order of a few 
seconds). To tackle this issue, [LISP-PRESERVE] and 
[LISP-ITR-GRACEFUL] propose techniques based on local failure 
detection and recovery. 


Middleboxes/filters: Because of the increasingly common use of 
encryption as a response to pervasive monitoring [RFC7258] with 
LISP providing the option to encrypt traffic between xTRs 
[LISP-CRYPTO], middleboxes are increasingly likely to be unable to 
understand encapsulated traffic, which can cause them to drop 
legitimate packets. In addition, LISP allows triangular or even 
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rectangular routing, so it is difficult to maintain a correct 
state even if the middlebox understands LISP. Finally, filtering 
may also have problems because they may think only one host is 
generating the traffic (the ITR), as long as it is not 
de-encapsulated. To deal with LISP encapsulation, LISP-aware 
firewalls that inspect inner LISP packets are proposed 
[lispfirewall]. 


Troubleshooting/debugging: The major issue that LISP experimentation 
has shown is the difficulty of troubleshooting. When there is a 
problem in the network, it is hard to pinpoint the reason as the 
operator only has a partial view of the network. The operator can 
see what is in its EID-to-RLOC cache/database and can try to 
obtain what is potentially elsewhere by querying the Map 
Resolvers, but the knowledge remains partial. On top of that, 
ICMP packets only carry the first few tens of bytes of the 
original packet, which means that when an ICMP arrives at the ITR, 
it might not contain enough information to allow correct 
troubleshooting. Deployment in the beta network has shown that 
LISP+ALT [RFC6836] was not easy to maintain and control [CCR13], 
which explains the migration to LISP-DDT [LISP-DDT], based on a 
massively distributed and hierarchical approach [CCR13]. 


Business/operational related:  Iannone et al. [IL10] have shown that 
there are economical incentives to migrate to LISP; however, some 
questions remain. For example, how will the EIDs be allocated to 
allow aggregation and hence scalability of the mapping system? 

Who will operate the mapping system infrastructure and for what 
benefits? What if several operators run different mapping 
systems? How will they interoperate or share mapping information? 


Reachability: The overhead related to RLOC reachability mechanisms 
is not known. 


6. Security Considerations 


A thorough security and threat analysis of LISP is carried out in 
detail in [RFC7835]. For LISP and other Internet technologies, most 
of the threats can be mitigated using Best Current Practices, meaning 
with careful deployment and configuration (e.g., filter), by 
activating only features that are really necessary in the deployment, 
and by verifying all the information obtained from third parties. 
Unless gleaning (Section 6 of [RFC6830] and Section 3.1 of [RFC7835]) 
features are used, the LISP data plane shows the same level of 


security as other IP-over-IP technologies. From a security 
perspective, the control plane remains the critical part of the LISP 
architecture. To mitigate the threats on the mapping system, 
authentication should be used for all control-plane messages. The 


Saucez, et al. Informational [Page 12] 


RFC 7834 LISP Impact April 2016 


current specification defines security mechanisms [RFC6836] 

[LISP-SEC] that can reduce threats in open network environments. The 
LISP specification defines a generic authentication data field for 
control-plane messages [RFC6836], which could be used for a general 
authentication mechanism for the LISP control plane while staying 
backward compatible. 
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